stream: fix async iteration of undefined chunks - #65969

Summary

Readable.prototype[Symbol.asyncIterator] throws an uncaught TypeError when an object mode stream carries an undefined chunk. This is a regression introduced by #64447, which replaced the async generator backing the iterator with a hand-rolled one.

Minimal repro

import { Readable } from 'node:stream';
await Readable.from([undefined]).toArray();

# v26.3.0
[ undefined ]

# v26.8.2
TypeError: Cannot read properties of undefined (reading 'then')
    at pump (node:internal/streams/readable:1507:26)

This is not specific to .map() / .toArray() — any for await over a stream containing an undefined chunk crashes. .map(() => undefined) is just an easy way to produce one.

Cause

The new iterator unwraps thenable chunks before delivery, but the null-check guarding the then access is too narrow. There are two affected sites, both in lib/internal/streams/readable.js:

• in pump() (line 1526 on main)
• in the buffered fast path of the iterator's next() (line 1599 on main)

Both read:

const chunk = stream.destroyed ? null : stream.read();
if (chunk !== null) {
  const then = chunk.then;   // TypeError when chunk is undefined

The guard is chunk !== null, but the dereference requires chunk != null. When stream.read() returns undefined the guard passes and chunk.then throws.

Because the throw happens in a microtask rather than rejecting the iterator's promise, it surfaces as an uncaught exception that terminates the process instead of a catchable stream error.

Why undefined is legal

doc/api/stream.md states in three places that an object mode chunk "can be any JavaScript value other than null", and that readable.push() accepts "any JavaScript value". null is reserved as the end-of-stream sentinel; undefined is a documented valid value. readable.push(undefined) returns true in object mode, so the stream accepts the value and then crashes on the way out.

Readable.prototype.read() signals "no data" with exactly null, never undefined (if (n > 0) ret = fromList(n, state); else ret = null;), so undefined coming out of read() is unambiguously a real chunk rather than an "empty" signal.

Fix

Read then with optional chaining at both sites, so undefined is delivered as a value while null keeps signalling end-of-stream:

const then = chunk?.then;

then is still read at most once, so a getter cannot observe (or throw on) a second access — the property #64447 deliberately introduced is preserved.

Tests

Adds three cases to test/parallel/test-stream-readable-async-iterators.js:

• an undefined chunk already buffered before iteration, exercising the synchronous fast path in next()
• an undefined chunk pushed after next(), exercising the pump() path
• Readable.from([undefined])

The first two cover the two distinct code sites, confirmed by stack traces on v26.8.2 (Object.next at readable:1580 and pump at readable:1507). All three fail before this change and pass after it.

Refs: #64447